What all Developers need to know about: Security Headers

Posted by Martijn van Lambalgen on August 1, 2018

— This post is part of a series of monthly blog posts about all kinds of Security topics for Developers —

Adding security headers is usually a quick win when improving the security of your web application, but nowadays there’s so many to choose from. Or shouldn’t you choose at all? Why not add all of them? How does this work? We tried to make an overview of which headers improve your security, and what they actually try to achieve for you.

Let’s start at the beginning. The HTTP protocol tells you to specify the HTTP protocol version, add a bunch of headers and optionally include a body for your request/response. The response headers can be thought of as meta data to the response, or as additional instructions for the browser. E.g. it tells the browser which content type the reponse page has, what server handled the request, or how long the requested resource can be cached. Below is an example of an HTTP response. The relevant security headers are marked in red.

Read more

About the author: Martijn van Lambalgen

Software engineer at TOPdesk interested in Software Architecture, Continuous Delivery and Web Security. Also wine drinker, good food lover, amateur baker and pleasure-seeker in general

More Posts

What all Developers need to know about TLS 1.0

Posted by Martijn van Lambalgen on June 4, 2018

— This post is part of a series of monthly blog posts about all kinds of Security topics for Developers —

TLS stands for Transport Layer Security and it is a cryptographic protocol to secure communication over a network. This is what is used when you type ‘https’ instead of ‘http’ in your browser to communicate with a server, but it is also used to secure other end-to-end communications like email, voice-over-IP or DNS. TLS is the successor of SSL (Secure Sockets Layer). Many people still use the word SSL when they actually mean a TLS connection. SSL is old and deprecated. Just like SSL, TLS 1.0 has been found to be insecure. This is why TOPdesk is slowly going to drop support for this protocol version in favor of version 1.2 (and soon also 1.3).  Here we’ll discuss what you need to know of TLS 1.0.

Read more

About the author: Martijn van Lambalgen

Software engineer at TOPdesk interested in Software Architecture, Continuous Delivery and Web Security. Also wine drinker, good food lover, amateur baker and pleasure-seeker in general

More Posts

What all Developers need to know about: Reverse Tabnabbing

Posted by Martijn van Lambalgen on May 2, 2018

— This post is part of a series of monthly blog posts about all kinds of Security topics for Developers —

It’s been a while ago when I first heard about reverse tabnabbing. Initially I didn’t think much of it, because exploits are not always straightforward. At TOPdesk we fixed any potential issues some time ago, but recently it’s getting more attention. I always applaud it when security topics get more attention, and therefore I’d like to explain here how we approach this at TOPdesk.

“Reverse tabnabbing” you say? What are you talking about? Never heard of this thing. Okay, so apparently it hasn’t gotten enough attention yet. Reverse tabnabbing can easily lead to some nasty phishing attacks. I originally read this article by Mathias Bynens on rel=noopener. It explains (and demonstrates) that if a site has a link to an external domain, and when you click the link, the site on the other domain gets full control over the parent’s  window object.

Read more

About the author: Martijn van Lambalgen

Software engineer at TOPdesk interested in Software Architecture, Continuous Delivery and Web Security. Also wine drinker, good food lover, amateur baker and pleasure-seeker in general

More Posts

What all Developers need to know about: Password guidelines

Posted by Martijn van Lambalgen on April 4, 2018

— This post is part of a series of monthly blog posts about all kinds of Security topics for Developers —

It’s time for our monthly security blog again.  Almost a year ago NIST published a new version of their password and digital identity recommendations. What are those recommendations, and why have they changed?

The new recommendations put an end to many of the crappy guidelines that we all hated, like requiring all kinds of special characters in your password, or having to change the password every x weeks. Slowly, people start to understand that these were not very good guidelines as they weren’t very well aligned with human behaviour.

Are you an ambulance driver, and need a password? Try ‘ambulance’. If the system also requires numbers, what about ‘ambulance1’? Special characters? Good chance that you will select ‘ambulance1!’. And next month, when the password needs to be changed, it will be ‘ambulance2!’, and so on. That’s what happens when you try to annoy people with these requirements. It gets ‘less’ secure, instead of ‘more’.

Read more

About the author: Martijn van Lambalgen

Software engineer at TOPdesk interested in Software Architecture, Continuous Delivery and Web Security. Also wine drinker, good food lover, amateur baker and pleasure-seeker in general

More Posts

What all Developers need to know about: Cookie Security

Posted by Martijn van Lambalgen on February 13, 2018

— This post is part of a series of blog posts about all kinds of Security topics for Developers —

Cookies are small packets of data which a server can send to your browser to store some configuration or personal data. The browser automatically sends them along with all requests to that same server. The contents are usually very interesting to hackers, so it’s important to know how to secure these cookies. Fortunately there are a lot of things you can do to improve cookie security. So… what do you need to know?

Read more

About the author: Martijn van Lambalgen

Software engineer at TOPdesk interested in Software Architecture, Continuous Delivery and Web Security. Also wine drinker, good food lover, amateur baker and pleasure-seeker in general

More Posts

What all Developers need to know about: Clickjacking

Posted by Martijn van Lambalgen on January 17, 2018

— This post is part of a series of blog post about all kinds of Security topics for Developers —

Clickjacking is still one of those amazingly simple attacks that are also easy to prevent. That is, if you know what clickjacking is, because considering the amount of websites that are vulnerable, not many developers know about this.

In a clickjacking attack, an attacker attempts to ‘hijack’ clicks by making the user think he is clicking something else. The basic idea here is that the attacker loads the thing he wants you to click on in an invisible iframe and then shows you something else. For example, you may see a button ‘Click here to get a Free iPad’, but when trying to click it the button, the click-event goes to a ‘Transfer $1000,- from my creditcard’ button in the invisible iframe. Clickjacking may cause all kinds of harm to the user. E.g. the hacker may get access to your webcam, steal money, send emails on your behalf, or worse… It is possible to hijack basically any type of event in the browser (like mouse events or key strokes) if the website that executes that action is not properly secured.

Read more

About the author: Martijn van Lambalgen

Software engineer at TOPdesk interested in Software Architecture, Continuous Delivery and Web Security. Also wine drinker, good food lover, amateur baker and pleasure-seeker in general

More Posts

Rolling updates in Kubernetes

Posted by Martijn van Lambalgen on January 8, 2018

So, you want to do rolling updates of your services in Kubernetes to achieve zero-downtime? That’s what we wanted to reach too, and what we’re doing now (mostly). Our journey involved quite a bit of research, filling of gaps in our lacking knowledge, learning from a multitude of mistakes, and a fair bit of trial and error. To make your journey more efficient, here is what we learned.

Read more

About the author: Martijn van Lambalgen

Software engineer at TOPdesk interested in Software Architecture, Continuous Delivery and Web Security. Also wine drinker, good food lover, amateur baker and pleasure-seeker in general

More Posts

Getting Docker Security Right

Posted by Martijn van Lambalgen on July 21, 2017

I started working with Docker at TOPdesk almost a year ago. Security is an interest of mine, so I did some research. You can’t look at Docker without thinking about Microservices, although they are separate topics. It is often said that Microservices can greatly improve your security. But also, that if you do it wrong, security can actually get worse.
So, what do you need to do to improve (Docker) security, rather than get rid of it? For most security concerns there is already a good solution, although not all of them are widely adopted. Let’s have a look at our concerns and how we take care of them.

Read more

About the author: Martijn van Lambalgen

Software engineer at TOPdesk interested in Software Architecture, Continuous Delivery and Web Security. Also wine drinker, good food lover, amateur baker and pleasure-seeker in general

More Posts

Public OWASP meetup to bring security to developers

Posted by Martijn van Lambalgen on March 22, 2017

At TOPdesk security is an important topic. It always has been, but in the last year the way we approach security is changing fast. We think we’re on the right track, and today we’re announcing the next step to help developers enjoy secure development.

Read more

About the author: Martijn van Lambalgen

Software engineer at TOPdesk interested in Software Architecture, Continuous Delivery and Web Security. Also wine drinker, good food lover, amateur baker and pleasure-seeker in general

More Posts

Code Reviews Done Right

Posted by Martijn van Lambalgen on January 20, 2017

(This story originally appeared on https://martijnvanlambalgen.wordpress.com/2016/12/27/code-reviews/)

Recently, I’ve read several articles, and heard multiple discussions on the quality of code reviews. To order my thoughts on this topic, I decided to write down my own ideas. Perhaps it helps someone, or it might lead to even more discussions.

So, what is a good code review? Obviously it depends on the situation. How big is the code change, how important is the feature, how many people are going to read that particular piece of code in the future, are there deadlines, etc. Let’s focus on the situation where there’s a reasonable amount of time available (no emergency fixes), for a feature change that has average importance, in a medium-sized team. Note that when I talk about a ‘code review’, usually I don’t just do a review of the ‘code’, but also of all the other parts my colleague has worked on. According to me the reviewer should for example also look at design and documentation, and check whether the acceptance requirements for the story have been met.

Read more

About the author: Martijn van Lambalgen

Software engineer at TOPdesk interested in Software Architecture, Continuous Delivery and Web Security. Also wine drinker, good food lover, amateur baker and pleasure-seeker in general

More Posts