Roel.io

Afgelopen week was ik bezig met het migreren van een aantal persoonlijke websites van shared hosting naar Linode. Na het overzetten van alle databases en bestanden stond er nog een klein puntje op mijn actielijst: alle HTTP security headers eens nakijken en (waar mogelijk) goed instellen.

Omdat het niet iets is wat ik dagelijks doe even een samenvatting. For future reference. ;)

Wat zijn HTTP headers?

Als jij een webpagina bezoekt wisselt de server waarop die website gehost informatie met jouw browser. Onder andere over hoe je browser moet omgaan met a) de verbinding naar die website en b) de inhoud van de webpagina. Een aantal van die headers kun je inzetten om je website beter te beveiligen, de zogenaamde security headers.

Om snel te checken hoe jouw website er nu voor staat kun je deze scannen met securityheaders.com. Mijn website begon met een F en scoort nu een A (goed), maar er zijn nog verbeterpunten.

Belangrijke security headers

Er zijn een aantal HTTP security headers beschikbaar om bepaald gebruik van je website te controleren of te beperken. Allemaal gericht op het beperken van risico’s voor bezoekers. Bijvoorbeeld:

• Strict-Transport-Security: hiermee kun je afdwingen dat browsers jouw website alleen via HTTPS inladen. Altijd aanbevolen als je al een SSL-certificaat hebt geinstalleerd.
• X-Frame-Options: om te voorkomen dat je website via een iframe in een andere website wordt ingeladen kun X-Frame-Options instellen. Bijna altijd aan te raden, behalve als je wil toestaan dat inhoud op andere websites 'ingesloten' wordt.
• X-Content-Type-Options: stelt vast dat browsers scripts en stylesheets niet mogen laden als de server niet het correcte MIME type meegeeft. Gericht op het tegengaan van XSS.
• Referrer-Policy: deze bepaalt welke informatie via de HTTP Referer header wordt meegegeven. Je kunt kiezen uit de complete URL van herkomst, alleen de domeinnaam van herkomst, maar je kunt ook kiezen alleen een referrer mee te geven naar andere pagina's binnen je eigen site.
• Permissions-Policy: via browser features en API's kunnen webpagina's toegang vragen tot je camera, microfoon, locatie, etc. Met een Permissions-Policy stel je beperkingen in welke web features je site mag gebruiken. En die gelden dan ook voor embeds!
• Content-Security-Policy: met een CSP stel je heel precies in welke bronnen vanaf welke domeinen mogen worden geladen. En of inline javascript (XSS risico) geladen mag worden. Op de infosec-website van Mozilla vind je meerdere voorbeelden van Content Security Policies.

Security headers instellen

HTTP Security Headers kun je instellen via server-configuratiebestanden, maar ook via plugins/modules van jouw CMS. De eerste optie vond ik het makkelijkst. Zoals altijd: maak even een back-up van de configuratie-bestanden voordat je iets wijzigt.

Op Nginx is dit mijn aanbevolen configuratie (in /etc/nginx/sites-available/sitenaam.conf) :

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;

Gebruik je Apache, dan kun je dit toevoegen aan je .htaccess file:

# HTTP security headers

Header set Strict-Transport-Security "max-age=31536000" env=HTTPS
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"

In deze aanbevolen configuraties mis je nog Content-Security-Policy, Referrer-Policy en Permissions-Policy. Hiervoor zul je je wel even iets moeten inlezen. De configuratie hiervan hangt af van de opzet van je site. Gebruik je daar 3rd party scripts (analytics) of stylesheets (web fonts)? En hoe belangrijk vind je het dat een referrer wordt meegegeven via kliks vanaf jouw website?

Maar als je voor jezelf die vragen hebt beantwoord ben je klaar. Toch? Nou nee, er zijn alweer nieuwe security headers in aantocht. En ook andere aspecten kun je waarschijnlijk verder aanscherpen (zoals DNSSEC). Met bijvoorbeeld Mozilla’s Observatory en Internet.nl kun je uitgebreider scannen hoe veilig jouw site geconfigureerd is. Bij de eerste scoort roel.io slechts een F 😞, bij de tweede pas 70 van maximaal 100 punten. Werk aan de winkel dus!

Verder lezen?

• Scott Helme, de maker van securityheaders.com, beschrijft hoe zijn bedrijf een pen test liet uitvoeren op een webapplicatie. Goed geconfigureerde security headers waren juist in die situatie waardevol.
• Op het blog van Savvii leggen ze nog eens begrijpelijk in het Nederlands uit wat je met security headers kunt en hoe je deze instelt.
• Mozilla heeft een uitgebreid web security guidelines document.
• Google Developer documentatie over Content-Security-Policy en een CSP-evaluatie-tool

Wendy Grossman (via Ton):

There was a time when a computer was a wholly-owned system built by a single company that also wrote and maintained its software; if it was networked it used that company's proprietary protocols. Then came PCs, and third-party software, and the famously insecure Internet. 5G, however, goes deeper: a network in which we trust nothing and no one, not just software but chips, wires, supply chains, and antennas, which Thomas explains "will have to contain a lot of computer components and software to process the signals and interact with other parts of the network". It's impossible to control every piece of all that; trying would send us into frequent panics over this or that component or supplier (see for example Super Micro). The discussion Thomas would like us to have is, "How secure do we need the networks to be, and how do we intend to meet those needs, irrespective of who the suppliers are?"

In other words, the essential question is: how do you build trusted communications on an untrusted network? The Internet’s last 25 years have taught us a key piece of the solution: encrypt, encrypt, encrypt.

Ons digitale leven wordt stapje-voor-stapje verder versleuteld. Berichten die we uitwisselen via Whatsapp zijn dat al (behalve in de back-up naar je iCloud-account), al zeker 80% van ons bezoek aan websites en langzamerhand ook de bijbehorende DNS-requests. Onze smartphones zijn standaard versleuteld, en moderne besturingssystemen bieden de optie ook. Nu onze e-mails nog. :)

Net als veel andere online gelijkgestemden schrok ik toen donderdag bleek dat 1Password, een van mijn favoriete apps, 200 miljoen dollar aan groeigeld had opgehaald.

Om Malik stelt ons op zijn blog een beetje gerust:

If you ask me, money won’t ruin 1Password. There are precedents for this sort of thing: Atlassian was a private, self-grown business that thrived for years before it took venture capital and then went public. The capital only helped expand its footprint. It continues to thrive.

Matthew Panzarino ziet ook geen aanleiding om ongerust te worden.

Om linkt in zijn artikel trouwens naar twee andere interessante stukken:

• The Ultimate Guide to Strong Passwords in 2019, en
• Passwords Are a Design Problem

Tips voor sterke wachtwoorden

De meeste tips uit Jon Xavier’s Gids voor Sterke Wachtwoorden kende ik al, maar het is goed om het nog eens op een rij te zetten:

1. Maak je wachtwoorden zo lang mogelijk. Hoe langer, hoe beter.
2. Gebruik geen speciale karakters of cijfers. Dat maakt je wachtwoorden niet veiliger.
3. Stel op iedere site (of app) een uniek wachtwoord in. Dus nooit hetzelfde wachtwoord op meerdere sites.
4. Gebruik een wachtwoord manager. 1Password, LastPass en Dashlane zijn bekende apps, maar er zijn er meer.
5. Wijzig je wachtwoord niet periodiek. Je hoeft het alleen te veranderen als de site/app gehackt is.
6. Gebruik tweefactorauthenticatie (2FA) waar mogelijk.
7. Vertel nooit de waarheid in je antwoorden op wachtwoord-herstel-vragen (Password Recovery). Lieg, of genereer unieke antwoorden met je wachtwoord manager.

Alle bovenstaande tips komen niet uit de lucht vallen, maar zijn juist gebaseerd op best practices van veiligheidsexperts. Het vreemde is alleen dat het totaal niet aansluit op het wachtwoordbeleid van alle grotere organisaties. Waardoor komt dat toch?