Info

Learning a little every day

Posts tagged security

Choose another tag?

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?

Security headers score roelioAls 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?

Foto van het boek van Huib Modderkolk

Vorige week las ik ‘Het is oorlog maar niemand die het ziet’. Daarin neemt onderzoeksjournalist Huib Modderkolk ons mee op zijn ontdekkingsreis door de digitale wereld. Waar het nog maar draait om één ding:

Ooit was het [internet] een uitwisselingsplek waar staten geen autoriteit hadden. Maar het grootkapitaal en de overheden hebben hun plek opgeëist. Het gaat niet langer alleen om verbinden, netwerken en communicatie. Hoe meer het internet het leven van mensen binnendringt via smart-tv, smartphone, slimme energiemeters en DigiD, des te meer gaat het over veiligheid.

Veiligheid, hét thema van de afgelopen jaren. Met twee duidelijk gerelateerde kanten:

  1. De gebrekkige beveiliging van veel systemen. Waar veel organisaties het afgelopen decennium de wrange vruchten van plukten. Zoals Diginotar en KPN.
  2. Het professionele hacken. Waarvan Stuxnet, de Russische cyberaanval op de Oekraïne (en indirect op de Rotterdamse haven) of de geavanceerde hack van Belgacom bekende voorbeelden zijn.

Hoe verstrekkend de Diginotar-hack wel niet had kunnen zijn vond ik opnieuw schokkend om te lezen. Net als het gebrek aan kennis bij politici en bestuurders over de basiselementen van onze digitale infrastructuur. Daar duurde het toch wat langer tot men zich realiseerde dat digitaal nu ‘best belangrijk is’.

En nog een trapje erger was — en is — de manier waarop organisaties hacks ontkennen of onder het tapijt proberen te vegen. Of het nu KPN is, of Belgacom, imagoschade voorkomen staat voorop. En wat dat betekent voor hun klanten of de rest van het land kan ze gestolen worden.
Wat dat betreft is gemeente Lochem gelukkig een positief voorbeeld: burgemeester Sebastiaan van ‘t Erve deelt juist overal en met iedereen wat er bij hen precies misging:

Lochem heeft alle onderzoeken (naar de hack, red.) openbaar gemaakt, om ervan te leren. Maar vooralsnog is deze gemeente de enige. Onverstandig, meent Van ’t Erve.

“Denk je nou echt dat die mensen alleen Lochem kiezen om in te breken? Dat moet ook elders zijn gebeurd. Maar je hoort er alleen niets over. We delen niets met elkaar. Want als iedereen gaat vertellen hoe het bijna fout ging, dan schrikken we uiteraard verschrikkelijk met z’n allen. Daarom doen we het waarschijnlijk niet.”

Onkunde, onwil en angst voor imagoschade gaan voor ons de komende jaren gevaarlijker zijn dan hackers in achterkamertjes. Maar er is ook een positieve noot: wereldwijd blazen de hackers van de AIVD een aardig deuntje mee. 🎺

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:

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?