Fronteers — vakvereniging voor front-end developers

Met Fronteerskorting naar dsgnday en CSS Day 2020

Op 11 en 12 juni houdt Web Conferences Amsterdam voor maar liefst de achtste keer CSS Day. Sinds een paar jaar wordt CSS Day voorafgegaan door een dag met presentaties rond een aan webdevelopment verwant thema. Dit jaar betekent dat een comeback van dsgnday!

Net als voorgaande jaren krijgen Fronteers-leden korting op dit congres. Wanneer je lid bent betaal je niet 600 maar 500 euro voor een kaartje voor beide dagen, of 275 in plaats van 325 voor een eendagskaartje (alle bedragen exclusief BTW). Het aanbod is geldig voor mensen die op dit moment al lid zijn, en je kunt ervan gebruik maken door een email naar het bestuur te zenden. Je ontvangt dan een eenmalig te gebruiken kortingslink waarmee je je kaart kunt kopen.

Bekijk voor meer informatie over de line-up de website van CSS Day en volg CSS Day op Twitter of op LinkedIn voor aankondigingen rond de laatste sprekers!

We wish you...

These last days of the year are a time to look back at what you did the past year and to look forward to what's to come. At Fronteers we can look back at a great year. We became a member of the W3C, Fronteers Conference was amazing as always and we hosted a couple of awesome workshops.

And we also have a lot to look forward to. We're gonna present a new design for our identity, we're starting work at our new website and of course there will be more workshops and in the autumn another edition of Fronteers Conference.

We hope you had a great 2019 and we wish you a happy christmas and a sparkling 2020. Of course, our volunteers have some new year's wishes for you too.

Jewwy

#fronteers + .everyone::before {
content: 'Happy New Year !';
position: absolute;
z-index: 2020;
background: #f2bb00;
color: #000
}

Jules

Happy and accessible 2020!

Job

While twenty-nineteen's almost empty
this new year has potential a-plenty
The fronteers volunteers
wish you a splendid new year's.
All the best to you in twenty-twenty!

Claudia

Best wishes for 2020 & let’s build a more #00FF00 web together! 💚

Paul

The Web is for Everyone. For you, you, you and you! And you. And a happy 2020!

Bernard

Have fun breaking your new year's resolutions! Wishing you all the best for 2020!

Michael

Best wishes for you and your loved ones for 2020!

Iain

Keep building a better web and a better world in 2020! Happy holidays and the best wishes for 2020.

Koen

Let's make the web a little more awesome in 2020. Have a great year!

Josee

I wish you a lovely, happy and fun 2020! Let's all do our share to make the world and the web a little better every day.

Board - Anneke, Edwin, Sander

The board of Fronteers wishes all front-end developers fantastic and semantic, styles with smiles, possibly some high-end destructuring assignment and above all, creativity aplenty in 2020!

What are your plans and wishes for 2020?

Cybersecurity: 4 tips voor developers

Denk je het volgende hypothetische scenario eens in: maandagochtend kom je op je werk. Je bent wat vroeger dan normaal, vandaag zelfs de eerste van je team. Terwijl de koffiemachine druk aan het malen is, maalt jouw hoofd ook. Deadlines, volle backlogs, sprintmeetings. Drukke dag. Je opent je e-mail. Een bericht valt op: vannacht om 02:47:35 was het systeem een minuut heel langzaam. Hoewel het niet jouw taak is, besluit je toch even te gaan kijken.

“Dit is wel heel vreemd”, denk je bij jezelf. Je hart begint harder te kloppen en je denkt: “met één medewerkeraccount zijn betaalinformatie en andere privé-gegevens van klanten bekeken in minder dan 53 seconden?” Je realiseert direct dat Herman dit niet zelf zou kunnen hebben gedaan. Sterker nog, hij zou niet eens toegang tot dit deel van de applicatie moeten hebben.

Het kleinste datalek kan een bedrijf al in een zeer slecht daglicht zetten. Als front-end developer heb je zeker invloed op welke beveiligingsmaatregelen genomen worden en kun je concrete voorstellen aan je projectmanager voorleggen. Maak in deze blog kennis met de basisterminologie en leer een aantal maatregelen die je kunt nemen. Inclusief kant-en-klare user stories.

Wat is hier gebeurd?

Uit het onderzoek in ons hypothetische scenario is gebleken dat Herman in de gedeelde kantine gebruik heeft gemaakt van de openbare wifi. Wat hij niet door had, is dat zijn laptop net overgeschakeld was naar dit netwerk. Wat hij ook niet wist, was dat er op dat moment een aanvaller op het netwerk zat met een proxy wifi station en al het verkeer erlangs leidde. En laat het nou ook zo zijn, dat Herman opnieuw moest inloggen, omdat hij op het nieuwe netwerk zat. Hij waande zich veilig op het bedrijfsnetwerk en dacht nog: "ik kan nog geen koffie halen of ik moet alweer inloggen".

In de tussentijd zit de aanvaller klaar: zij heeft haar aanval zo opgezet dat het doelwit niets door heeft. Ze kan alle pagina's zien en zodoende ook de logingegevens achterhalen. Zo kwam de aanvaller aan de logingegevens van Herman. En daar stopte het niet. Zij kon het verkeer onderscheppen en dat gaf haar inzicht in de opzet van applicatie.

Hoewel de rol van Herman maar klein was, laat de directeur er beslist geen gras over heen groeien: hij wordt bij binnenkomst direct apart genomen en op non-actief gezet.

Wat ging er wel goed?

Goede punten zijn er ook. Uit dit verhaal blijkt dat bepaalde acties gelogd worden met het bijbehorende account en dat er monitoring is van bijzonderheden, zoals errors, laadtijden en dergelijke.

Hieronder volgen een aantal suggesties die je kunt uitvoeren waardoor een dergelijke aanval veel lastiger succesvol uit te voeren is.

Begrippen

De browser doet bij een bezoek van een website een HTTP request en daarop volgt bij succes dan een reponse die verdeeld is in response headers en een reponse body (bijv. HTML, CSS en JS). In deze headers kun je informatie kwijt die de browser gebruikt om bepaalde maatregelen in te schakelen.

Mitigatie: Mitigatie is matiging, verzachting, vermindering. Of een aanval(ler) succesvol is, ligt aan veel factoren. In de context van cybersecurity betekent dit dat een beveiligingsmaatregel ervoor zorgt dat een mogelijk aanval minder succesvol, moeilijker of helemaal onmogelijk wordt.

1. Bescherm je cookie

User story: bescherm gebruikers tegen session hijacking

De eerste tip is cookie-hygiëne. Zorg ervoor dat (sessie)cookies beschermd zijn met deze extra (los van elkaar te gebruiken) instellingen: HttpOnly, Secure en SameSite. Hiermee wordt session hijacking en CSRF (Cross Site Request Fogery) lastig voor een aanvaller.

HttpOnly cookies hebben een bijzondere eigenschap: ze kunnen niet worden uitgelezen of bewerkt door de browser. Dus ook niet door third-party scripts. HttpOnly cookies kunnen alleen worden ingesteld door de server en worden alleen automatisch meegestuurd bij elke HTTP-request. Dit is handig voor sessiecookies.

Door een cookie de Secure-flag te geven, wordt deze alleen verstuurd over HTTPS-verbindingen door de browser.

De SameSite-flag is relatief nieuw en daarin kun je aangeven dat een cookie uitsluitend naar zijn eigen domein verstuurd mag worden: SameSite=strict. Zo voorkom je dat jouw cookies bij HTTP-requests naar andere domeinen meegestuur worden. Lees meer over SameSite cookies.

2. Gebruik een XSRF-cookie

User story: bescherm gebruikers tegen CSRF

Een moderne browser geeft een XSRF-cookie alleen mee aan POST-, PUT-, DELETE-requests die naar dezelfde domein gaan. Dit biedt zo een extra check om CSRF-aanvallen te voorkomen. Als deze cookie niet aanwezig is, is de gebruiker niet geauthenticeerd.

X-CSRF-Token: value

De naam token suggereert dat hier een token voor gegenereerd moet worden, dit is echter optioneel. Hier kan elke value worden gebruikt. Uiteraard kun je er natuurlijk wel een token inzetten, als je dat zo wenst.

3. Content Security Policy, in kort: CSP

User story: gebruikers moeten maximaal beschermd zijn tegen XSS (Cross Site Scripting)

  • Browsers bevatten steeds meer features, variërend van toegang tot de camera en microfoon tot het sturen van notificaties.
  • Stel dat een aanvaller het voor elkaar krijgt om een klein stukje JavaScript aan een pagina toe te voegen, dan heeft hij of zij toegang tot alle features, formulieren en andere acties van een gebruiker. De verkregen gegevens kunnen dan weer doorgestuurd worden naar een andere website.
  • Zo kan een aanvaller potentieel gevoelige gegevens skimmen (ofwel ‘steelt’). Denk bijvoorbeeld aan creditcard-gegevens op een checkout-pagina, logingegevens of BSN-nummers op een pagina van een zorgverzekeraar. Een gebruiker heeft dit niet door en kan zich hier nauwelijks tegen wapenen.

Gelukkig is dit te mitigeren met behulp van Content Security Policy (CSP). Moderne browsers ondersteunen dit sinds kort.
Met behulp van CSP kun je exact specificeren bij het inladen van de pagina welke onderdelen van de browser gebruikt mogen worden, vanaf welke domein en zelf met welke hash. Als de websites dan toch een van deze features aanroept of een script probeert in te laden, dan faalt dit. Zo wordt het voor aanvallers iets lastiger: voordat ze een script kunnen uitvoeren moet eerst CSP worden uitgeschakeld.

Implementatie van CSP kan op twee manieren: je kunt een HTTP-header toevoegen of in de HTTP-reponse een <meta>-tag toevoegen. Op de website van MDN kun je uitstekende voorbeelden vinden.

Soms is de implementatie hiervan niet eenvoudig. Het is bijvoorbeeld lastig als je website veel third party scripts inlaadt of vanaf meerdere domeinen api calls moet doen. Wat je dan als tussenmaatregel zou kunnen doen is het beschermen van bepaalde pagina's met gevoelige gegevens. Op een login- of betaalpagina bijvoorbeeld wil je geen third party scripts draaien.

Doel: Voorkom dat een pagina iets kan doen wat je niet nodig hebt, maar een aanvaller wellicht wel. Door exact te specificeren welke features een browser mag gebruiken, kun je bepaalde aanvalsvectoren onmogelijk maken of het effect ervan beperken.

4. Mitigeer downgrade aanval

User story: als gebruiker wil ik altijd een HTTPS-verbinding.

  • Veel websites met een HTTPS-verbinding kunnen ook nog bereikt worden via HTTP.
  • Een aanvaller kan proberen om de gebruiker om te leiden naar de HTTP-versie en zo het verkeer monitoren of zelf bewerken, zoals bij Herman in ons hypothetische verhaal.
  • Dit heet een *downgrade aanval*. Hier kun je twee maatregelen tegen nemen om dit (deels) te voorkomen.

A. Gebruik HSTS (HTTP Strict Transport Security) door dit HTTP-responseveld toe te voegen: Strict-Transport-Security: max-age=60000. Als een browser dit detecteert, onthoudt deze voor een bepaalde periode dat altijd de HTTPS-website geopend moet worden.

B. Mochten er nou toch nog non-HTTPS verbindingen worden gemaakt, zorg er dan voor dat elk HTTP-request automatisch wordt geredirect naar HTTPS. Dit kun bij Apache in de .htaccess ingestellen of bijv. met Express (Node.js webserver) met middleware.

Hier stopt het niet... een paar tips

De hierboven genoemde maatregelen zijn maar een kleine selectie van acties die je zelf concreet kunt nemen. Er is nog veel meer mogelijk. Kijk bijvoorbeeld eens naar onderstaande tips.

  • Luister naar de podcast Darknet Diaries.
  • Voeg 2FA toe met bijvoorbeeld een time-based one-time password.
  • Laat een penetration test uitvoeren. Probeer maximaal te leren van zo'n team dat langs komt en lees het verslag van top tot teen.
  • Leer meer over Same Origin Policy.
  • Leer meer over Subresource Integrity.
  • Lees Security Droplets
  • Pas op met deze header Access-Control-Allow-Origin: *. Een aantal van de hierboven beschreven maatregelen kunnen minder effectief gemaakt worden.
  • Bespreek het onderwerp ‘cybersecurity’ in je team. Er is een goede kans dat er iemand bij zit die direct wat verbeterpunten weet om Herman te redden.

Op naar een veiliger decennium!