Fronteers — vakvereniging voor front-end developers

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!

Clichés op het web

Letterlijk is een ‘cliché’ een metalen plaat waarmee je illustraties kunt afdrukken. Figuurlijk is een cliché een afgesleten manier van spreken of denken. De eerste keer dat je een grap maakt, is ‘ie leuk. De tweede keer is ‘ie al minder. Na tien keer is ‘ie saai. Clichés zijn de doodgeslagen cola van je denkvermogen, om het op z’n BLØFs te zeggen.

Een cliché voor reclame voor King pepermunt

Een cliché voor reclame voor King pepermunt

Clichés zijn niet per definitie onwaar of fout. Het kan heel handig zijn om in clichés te denken. Het is doodvermoeiend en zonde van je tijd om altijd overal over na te denken. Clichés helpen je dan, zodat je niet te lang hoeft na te denken. Maar je moet niet alles geloven wat je denkt, want soms is wat je denkt gewoon fout.

Sommige clichés zijn bijna niet uit te roeien. “Als anderen het doen, zal het wel goed zijn.” Een klant van me vroeg laatst wanneer ik een cookie-waarschuwing op de site zou plaatsen. Waarom? Omdat iedereen het doet, dus hoort een cookie-waarschuwing op elke website.

Aaargh.

Cliché 1: ‘Een plaatje zegt meer dan 1000 woorden’

Sure, maar welke 1000 woorden zegt jouw plaatje? Zegt je plaatje “Ik had geen tijd om een goede foto te zoeken”?

Plaatjes-omdat-het-moet

We zijn gewend geraakt aan enorme hero images, schermvullend en topzwaar. Hierdoor denken we dat bij elk bericht een foto hoort. Het probleem is dat niet iedereen een geweldige foto-bibliotheek ter beschikking heeft. Het resultaat? Websites vol plaatjes-omdat-het-moet. Het liefst clipart met teksten die verkeerd afgesneden worden. Fotoredactie is het ondergeschoven kindje van modern webwerk.

Screenshot van Frankwatching.com (november 2019)

Screenshot van Frankwatching.com (november 2019)

Stockfoto’s

Niet iedereen heeft een geweldige smaak of fantasie, sorry dat ik het zeg. En even een plaatje googelen is een fluitje van een cent.

Resultaat? “Aap eet banaan“, een uitdrukking van ontwerpers voor een ontwerp dat er te dik bovenop ligt. Denk aan een hamer als logo voor een timmerman. Een aap-eet-banaan-slogan is: ‘Voor al uw timmerwerk’.

Ariane The Overexposed Stockphoto Model

Ariane The Overexposed Stockphoto Model

Zoek op “Success”

Zoek op “Success”

Zoek op “Men shaking hands”

Zoek op “Men shaking hands”

Zoek op “Boy toys”

Zoek op “Boy toys”

Zoek op “Girl toys”

Zoek op “Girl toys”

Zoek op “Woman eating salad”

Zoek op “Woman eating salad”

Zoek op “Hacker”

Zoek op “Hacker”

Icoontjes

En icoontjes? Breek me de bek niet open over icoontjes. Alles wordt begrijpelijker door icoontjes zeg je? Hmmm, kijk ‘Repelsteeltje – Guess My Name’ nog eens terug, een hilarische presentatie van Mallory van Achterberg over onbegrijpelijke icoontjes.

Cliché 2: klik hier en lees meer

Opa vertelt: er is een tijd geweest dat het internet zo nieuw was dat je alles moest uitleggen. Dat was de tijd dat we URLs in reclame volledig uitspelden. “Ga naar haa tee tee pee dubbele punt slash slash wee wee wee nu punt en el voor het laatste nieuws”, ofzo. Je wist niet beter, je had niets anders. Dus je moest ook het principe van een klikbare link uitleggen. Uit die tijd stamt de irritante gewoonte om ‘klik hier‘ als linktekst te gebruiken. ’t Liefst 1 woord ja.

Klik me dan, als je kan

Moet ik nog vertellen waarom dat een slechte gewoonte is? Ten eerste geldt: hoe kleiner het klikbare gedeelte, hoe moeilijker het is om er op te klikken (zie deze uitleg van Fitt’s Law). Ten tweede: ‘hier’ beschrijft niet waar je heen gaat. Je vertelt je gebruiker niet wat hij op die nieuwe URL kan verwachten. Dat is niet aardig. Wees aardig voor je bezoeker.

Lees meer, meer, meer!

De tweelingbroer van Klik Hier is Lees Meer. Ook met ‘lees meer’ vertel je niet waar je naartoe gaat. Je hebt pech als je afhankelijk bent van een screenreader om wijs te worden uit een pagina met twintig keer een link met ‘lees meer’ als tekst. Beschrijf met je linktekst alsjeblieft waar je heen gaat en maak deze tekst uniek voor je webpagina. Mocht je omwille van het design van je pagina toch veroordeeld zijn tot korte linkteksten, gebruik dan een list. Gebruik bijvoorbeeld het ‘aria-label’-attribuut als alternatief, of gebruik de titel van de pagina waarnaar je verwijst als linktekst, maar verberg die louter visueel.

Stapels boeken

Dit is een prima aansporing: “Lees meer”, als je bedoelt: lees meer boeken

Klik anders hier even: click-here.nl

Cliche 3: Social media-knoppen

Social media knoppen

Klik hier

Die knoppen om een pagina te delen op social media? Ze werken amper. Ik ken geen onderzoeken die aantonen dat ze een groot effect hebben op het wel of niet delen van een pagina. Maximaal 1% van je bezoekers gebruikt die knoppen om een pagina te delen.

Waar ze wel goed voor zijn? Eh.

Ze zijn vooral bedoeld om je opdrachtgever het fijne gevoel te geven helemaal hip & happening te zijn, want als je niet op sociale media meedoet besta je niet.

Satansboek

Afhankelijk van hoe je die knoppen implementeert kun je het satanische Facebook helpen om je bezoeker over het hele internet te achtervolgen.

Hmmm, privacy.

Cliche 4: lage bounce rate

Bounce rate is een marketingterm voor het percentage van je bezoekers die na het eerste bezoek aan je site weer vertrekken; “Hee, hoi” en ze stuiteren weer door, zeg maar. Hoe lager je bounce rate, hoe meer je bezoekers doorklikken naar een volgende pagina op je site.

Een hoge bounce rate is niet erg.

Sterker nog: een hoge bounce rate zou kunnen betekenen (aanname!) dat je bezoeker exact gevonden heeft wat hij (m/v/a) wilde. Na zijn succesvolle bezoek aan je website sloot hij zijn laptop, ging naar huis en knuffelde zijn kind, zijn hond en zijn kat.

Wil je je bezoeker tevreden stellen of wil je ‘m bezigheidstherapie geven?

Cliche 5: cookie-waarschuwingen

Het web is ziek. Cookie-waarschuwingen zijn daar het symptoom van. Veel websites staan vol meuk om elke klik vast te leggen: pixels, beacons, fingerprinting, dynamic cookies, en what have you not. Anno 2019 is het web een panopticum waarin elke stap van je bezoeker doorgegeven wordt aan de Googles, Facebooks en geheime diensten van deze wereld. Dankzij Edward Snowden kennen we de details en ja, die zijn echt heel erg. Onze gegevens liggen inmiddels op straat.

Cookies tegen heug en meug

Cookie-waarschuwingen zijn bedoeld als pleister, om bezoekers meer controle te geven over hun gegevens. Helaas komen de meeste cookiemeldingen neer op: “Cookies: we zetten ze en we laten alle advertentieboeren ook meekijken en je hebt het er maar mee te doen.” Ik denk even aan de 1000 ongevraagde cookies op de site van TV Rijnmond.

Aksie, harde aksie!

Daarom denk ik dat het goed is dat we als front-enders veel meer weerstand bieden tegen mogelijke schendingen van de privacy van onze bezoekers. Vraag je bij elk formulier dat je maakt bijvoorbeeld:

  • Waarom vraag ik dit van de gebruiker?
  • Moet ik een binair geslacht weten? Welke ramp gebeurt er als ik straks niet iemand aanspreek met ‘Geachte mevrouw’, maar met ‘Hallo’ of ‘Goedendag’?
  • Moet ik echt een telefoonnummer vragen?
  • Wat gebeurt er straks met al deze gegevens?
  • En wat als deze gegevens op straat komen te liggen?

Uiteraard wil je weten hoeveel bezoekers je hebt op je site. Maar moet je echt Google mee laten kijken? Google weet welke zoektermen je bezoeker gebruikte en dankzij je niet-geanonimiseerde Analytics-tracker weet het ook hoe snel je bezoeker weer wegstuiterde van je site. Gebruik betere analytics tools, die niet stiekem data doorverkopen aan adverteerders. Advertentieboeren zijn de keyloggers van het internet. Het is tijd dat we het heft weer in eigen hand nemen. Baas over eigen data.

Cliche 6: formuliervelden zonder labels

Ik denk dat het onkunde is dat er zoveel formulieren zonder fatsoenlijke labels te vinden zijn. Het is nogal simpel. Heb je een <input> dan hoort daar een <label> bij. Geen mitsen, geen maren: er hoort een label bij. Ik herhaal het even: geen placeholder, geen vet tekstje. Nee, een zichtbaar <label>.

<label for"tralala">
<input type="text" id="tralala" name="voornaam" placeholder="Je voornaam" value="" />
</label>

Weet je wat daar zo handig van is? Je vertelt daarmee aan je gebruiker wat hij moet doen.

Liftknopjes zonder nummer

O jee, geen labels. Wat nu? Het origineel is trouwens niet veel beter.

Cliche 7: niet-onderstreepte links

Er zijn designers die zeggen: “Onderstreepte links zijn niet mooi.” Ik vind: suck it, hou je links herkenbaar. Vanaf het begin der tijden zijn links onderstreept en blauw. Heb je de link al bezocht dan is de link paars. Wapper je er met je muis overheen, dan wordt ‘ie rood. Zo deden we dat vroeger, zo deden onze voorouders het, zo deden de Neanderthalers het. Links zijn onderstreept.

“Ja maar, ik heb m’n links een andere kleur gegeven!”

Prima, maar wat als je bezoeker nou moeite heeft met kleuren zien? Dan is het heel fijn om niet op kleur alleen te vertrouwen. Dus ik zeg: onderstreping. Superhandig.

Conclusie?

Ik heb een paar willekeurige clichés gekozen om over te klagen. Waar dit wat mij betreft op neerkomt is:

  • Hoe minder je bezoeker hoeft na te denken over je site hoe beter het is.
  • Hoe minder meuk wij vragen van onze bezoeker, hoe beter het voor hem is.
  • Hoe beter we nadenken over het hoe en waarom we websites maken, hoe beter het voor iedereen is.

We moeten wat liever zijn voor onze bezoekers en de boel niet te moeilijk maken.

Vrede op aarde.

(Dit is een vertaling van een praatje dat ik eerder gaf bij de Fronteers Jam Sessions in oktober.)