Security is a topic that is often poorly understood by developers because many of them focus on the technical side of security rather than the wider topic which involves people, money, risk and business priorities. As a result we often see poor decision making, unnecessary complication and wasted resource.
It's important that developers when building or choosing security solutions pick the correct one for their business or organisational situation. And it's particularly important that junior developers understand the wider context within which security decisions should be made.
1. Avoid dogma and absolutism
In a recent dev.to article a contributor shared the following advice on the topic of JSON Web Tokens and local storage.
The biggest security offenders I see today are those of us who store JWTs (session data) in local storage. Many people don't realize that JWTs are essentially the same thing as a username/password. If an attacker can get a copy of your JWT, they can make requests to the website on your behalf and you will never know. Treat your JWTs like you would a credit card number or password: don't ever store them in local storage.
The post which this advice comes from is good, it's definitely worth a read, and covers many important issues relating to JavaScript local storage. Sadly though this statement on JWTs and security is misguided or at least lacks the nuance that developers need to understand.
The position taken on JWTs and local storage is an absolute one, "Don't do it!!" But where you store a JWT is not really of great importance, and storing it somewhere 'safe' doesn't guarantee security. The important questions to ask are, what are you storing in the JWT? And, what are you using the JWT to do or access?
If the answer to those questions doesn't include any Personal Identifiable Information, or includes minimal PII, then you can probably do as you wish with those JWTs. If by contrast your answer to the above questions is, "All their credit card information!!" Then you should probably consider an alternative technology to JWTs.
As an example, if you were to implement a content paywall as many online news publications now do JWTs stored in local storage will be a perfectly acceptable security solution. The content you are protecting is of low value, no PII, so the likelihood that a hacker will be interested in hacking this content is very low. JWTs though will stop your average 'run of the mill' web user from accessing the content without paying for it. A simple solution to a security requirement.
You'll note that this approach to solving a security problem is less dogmatic and absolutist. There is a tendency among talented developers to become dogmatic and absolutist, possibly because everything they see is 'bad' or at least less than perfect. A little like when Plato looked upon Athens in the 5th century BC, but like Plato this approach can lead to poor solutions and bad answers. And it can be unhelpful for those attempting to understand a topic, particularly if they are junior.
It is sensible when dealing with security to avoid dogma, absolutism and one size fits all statements. There isn't an equivalent to the moral absolute "Do not murder" as security involves more nuance.
2. There is no such thing as security
There is a great irony at the heart of security, which is that it doesn't exist. Recently Google Chrome announced on Twitter that they will be marking all sites using HTTP as "Not Secure". They already mark HTTPS sites as "Secure" in the URL bar.
🔐⚠️ The moment we've all been waiting for! Chrome will mark all HTTP sites as "Not secure" in July 2018. 🔐⚠️https://t.co/2eV4GuEa2y
— emily schechter (@emschec) February 8, 2018
This is bizarre as HTTPS, or HTTP via TLS, is a very useful security enhancement but does not guarantee security. It is perfectly possible to build a site and serve it via HTTP that is more secure than a site served over HTTPS.
Google's actions here are surprisingly irresponsible as they could encourage average web users to feel safe when they are not and so be less cautious in their actions and behaviours online. And this is without covering the topic of how the HTTPS connection is implemented, see CloudFlare flexible SSL. A more sensible approach may be to describe the connection as "Private" or "Public", but "Secure" or "Not Secure" is misleading.
There has never been anything that has been completely secure, and even with all the technical advancements we've made there still isn't. Security has always been relative to what is being protected. People have spent millennia building walls of one type or another, but no-one has ever succeeded in building an impregnable dome.
If you don't believe me just ask the Iranians. In 2009 the Americans, definitely with the help of the Israelis and probably the British, hacked into an Irainian Nuclear facility called Natanz. You'll probably remember reading about the Stuxnet virus which was the likely culprit. What is extraordinary about the hack is that the Natanz facility was air gapped and probably one of the most secure facilities in the world. This though did not stop the Americans from getting a virus into the facility and disrupting Iranian nuclear production processes.
If you're interested in this topic and stories like this I suggest you read Gordon Corera's book Intercept: The Secret History of Computers and Spies. It's a wonderful book that will contextualise the topics of security and hacking for you.
Good security involves building a wall that is higher than the value of the assets you're protecting. That is it will cost a hacker more to hack your system than they will gain from hacking it. This also means your security should be proportionate to what you are protecting. Don't for example air gap a server to protect a few email addresses you've collected from a web sign up form, that would be an extraordinary waste of money.
3. Understand the threat
When building your wall it is important to understand the threat you face. Security threats can be broken down into four basic groups:
- Kiddy Scripters and Automated Threats: See most WordPress / Joomla hacks.
- Skilled Hackers and Hacker Organisations: Anonymous, LulzSec
- Organised Crime and Minor State Actors: The Mafia, North Korea
- Major State Actors: USA, China, Russia, Israel, UK
The majority of developers will rarely deal with anything above level one. The reason for this is two fold, you have to be doing something of significant financial value and or of significant political value to move above level one. Examples of this would be sensitive government work, aspects of financial work and aspects of major corporate work.
Also the threats are diverse and won't necessarily relate to hacking data. For example your organisation may be much more vulnerable to a DDOS Attack than a data breach. As a developer it's important you consider how your organisation might be vulnerable, and the primary vulnerability may not always be financial or PII focused, it could be reputational. Embarrassing your organisation by taking your website offline may be of far greater value to hackers than stealing the PII you have on your servers.
The Fappening in 2014 is a good example of an organisation failing to understand a threat properly. In this case Apple failed to properly value the content they had on their iCloud system and therefore did not implement security features that could have limited the damage. For example sending out emails when a new device or strange IP connected to an account. The Fappening was an edge case as no-one had really considered the value of celebrity data before, but it does highlight that the threats organisation face may not always be logical.
4. Implement a proportionate solution
If you implement generic security solutions without properly considering the threat you face you may be no safer than if you implemented no security at all.
As a developer you must seriously consider the threats you face before you implement any security solutions. This is so that you can implement proportionate security measures. Proportionate does not simply relate to the security threat though, it also relates to how much money you have to spend. A poor nation cannot build the Great Wall of China, but it can defend itself if it understands the threat and deploys its resources sensibly.
Much of the world enjoys laughing at North Korea, Kim Jong Un and his crazy nuclear plans. However behind the madness there may be some logic. There is a theory that North Korea has recognised that America and the West has happily carried out regime change against Afghanistan, Iraq and Libya, but has been much more cautious in relation to Iran and Pakistan. The theory goes that this is because Iran may have nuclear weapons and Pakistan does have nuclear weapons. North Korea has recognised this and is rushing to build a bomb and missile so it doesn't become the next Iraq. It has assessed the threat and is responding logically given its limited means, and it may succeed in defending the North Korean regime from America's bombs. Nuclear bombs may not protect them from their own people in the end though.
I'm not advising you follow North Korea's example, however you should consider what is a proportionate security response given your organisation's resources. This is particularly important given very few of us work at Apple, Google or Facebook. Most organisations have limited resources and they cannot justify spending large sums of money on security features that only produce marginal gains. When considering your security response you should begin by asking the following three questions.
- What am I defending and how valuable is it?
- Who is it that poses me a threat?
- How much resource does my organisation have to defend itself with?
If the answer to these questions are low value, limited threat and low resources, then the basics will suffice. For example securely encrypt passwords, don't store too much PII, implement CSRF policies, etc, etc. If the answers are at the opposite end of the scale then you will have to consider much more advanced security features. And if the answers are mixed you may have to compromise in certain areas.
The overarching point here is that there is no 'one size fits all' security solution. So dogma and absolutism simply don't apply to security. When thinking about security consider what you're protecting carefully and then do an analysis of likely threats. After this build your wall with the resources you have available.
Top comments (21)
One thing, I'd mention too, although potentially obvious, but it never hurts to state the obvious, is to always apply the principle of Least Privilege.
Interesting, tell me more. I haven't heard about that before.
Give your users, services, etc. the least amount of privileges necessary to function and no more. For example, I recently watched a security video on how to hack AWS Lambda. Pretty much all the exploits depended on the admin being lazy and giving the IAM account all privileges (
*) rather than creating multiple accounts and customizing the capabilities of each one to the task at hand.👍 Thanks for providing the explanation Kasey, was in a meeting before, so didn't have time to respond.
For reference, I came across this in 2014 while working on Identity Access Management (IAM) for a bunch of SharePoint applications that were using WS-Federation, SAML etc. Although the code is generally related to C#, this was a great blog I used at the time, leastprivilege.com.
Dominick Baier, the author of this blog, is well versed in IAM, specifically on the .NET platform. If you're in that ecosystem, you should check out, github.com/identityserver
We use IdentityServer for one of our systems, actually.
Our client ended up going with commercial software. We set them up with Optimal IdM. Great product and support. We needed an on premise solution, so it fit their needs. The virtual feature allowed us to expose all the clients' user stores as one.
Ah that all makes a lot of sense. We've recently gone through a process of doing that at work.
@robdwaller , here's a real world example that occurred yesterday.
Why people run npm with
sudomakes no sense to me as you don't need to.In this particular case, by giving npm too much privilege, it wreaked havoc on Linux file systems, Show-stopping bug appears in npm Node.js package manager | ZDNet.
Had npm been run with a non-root user (least privilege), this would not have happened. The issue has since been fixed with a patch.
I have to admit I hate NPM. I've scrapped entire boxes and started over because I've messed up an NPM install. It always feels more like sorcery than actual Dev ops. Always advise developers to be careful with Node and NPM.
Also would be remiss without linking this:
Principle of Least Privilege
But that's just more dogma too. Don't get me wrong, the principle of Least Privilege is a fantastic security tool, but it comes a cost, and sometimes what you're protecting just isn't worth that cost. For example, I run my own server which handles my mail and runs my blog, and I also run an always connected IRC client through screen on it. Principle of Least Privilege would say that I should use a different user account that doesn't have the ability to admin my web and mail server for running my IRC client. But I don't, because the value of my mail and web server isn't that high, not high enough to outweigh the cost of managing multiple use accounts and SSH keys for logging in to the one server. That's a pragmatic decision I've made after understanding the threats.
Good article, I like how you boil down a complex issue into a simple set of questions. Thinking about security is the first challenge for many people. I also agree to your comments about Google and their movements with regards to HTTPS. It's a step in the direction of being more secure but like you said, being a HTTPS website doesn't make the application completely secure.
Really pleased you think so. I just think the Google Chrome position is odd given the influence they have over the web.
Hey Rob, a few good points in there.
With regard to Dogma, I feel it's often useful to follow the "Dogma" (ie, advice of the experts) in the area's you dont have a good understanding of, rather than dismissing it as Dogma. On a personal note, I wish more products treated access to Personally Identifiable Information with more security than credit card numbers. At least I can change my credit card, much harder to change my DOB.
"It is perfectly possible to build a site and serve it via HTTP that is more secure than a site served over HTTPS".
Could you elaborate on that statement? Otherwise I feel it does considerable more harm than any good it does to have in the article.
Golden -> Implement a proportionate solution
Hi Thomas,
Thanks for the comment and feedback, sorry I haven't responded to this sooner, I've been a little busy with work and other things...
To answer your questions, I absolutely agree that it's sensible to follow the advice of experts. I just believe there is a difference between this and following dogma which can be counterproductive.
In terms of of HTTP vs HTTPS: A Jekyll / Static site served over HTTP is likely more secure than a WordPress / Drupal site served over HTTPS. My point was simply that HTTPS does not guarantee security, merely increases it. You shouldn't implement HTTPS and assume you're safe.
I hope that answers your questions.
Hi Rob, No worries.
I think your statement about Site Security and HTTPS is conflating two very different aspects of security to the point of being harmful to a less-informed reader.
I'd argue that HTTPS in no way increases your site's security (for some definition of security). Any expectation that is does is misinformed. What is does do is well documented by others such as Troy Hunt, so I'll link to that rather than poorly attempting to make the same point. Overall HTTPS is about the security of your visitors, not how hackable your own platform is.
troyhunt.com/dont-take-security-ad...
troyhunt.com/the-6-step-happy-path...
It's certainly not dogma, but just good practice, and with the prevalence of services like CloudFlare and LetsEncrypt, the barrier to entry is pretty much zero now.
Cheers!
Great article Rob! I use the following mantra(s) when talking to technical teams about information security, I think they line up well with yours:
I also talk about security frameworks such as Gartner's Adaptive Security Architecture (Predict, Prevent, Detect, Respond), breaking each of these terms down with examples of technologies or processes used. This helps make infosec less abstract, especially if I can include some war stories!
I like the "Know you are wrong" mantra, it can be applied to all levels of development. As soon as you think something is working it's most likely broken in some way... :)
Very nice article.
I would like to add that in my opinion, the weakest link in every system are users. Of course, we should secure our systems itself but users awareness is the most valuable thing.
Cheers.
The biggest security hole in your business or organisation is always the people. I didn't touch on social engineering but most businesses are probably more vulnerable to it than a data hack.