Waarom je stil moet staan bij frontend security

Deze blog is geschreven door Christiaan Bakker, frontend developer bij Triple.

Na het bijwonen van de presentatie van Zoë Rose getiteld 'Hear no Evil, See no Evil, Code no Evil' over de rol van developers in beveiliging tijdens de Full Stack Europe-conferentie in oktober 2022, begon ik dit op mezelf toe te passen. Inderdaad, als frontend developer nam ik vaak aan dat beveiliging de verantwoordelijkheid was van de backend en TechOps, maar is dat echt zo? In deze blog bespreek ik welke stappen je als frontend ontwikkelaar kunt nemen om de softwarebeveiliging te ondersteunen.

Risico's voor front-end beveiliging en hoe je ermee om kunt gaan

Als frontend developer moet je verschillende risico's in overweging nemen bij het ontwikkelen van een applicatie. Hieronder zal ik enkele van de meest voorkomende risico's bespreken en enkele richtlijnen geven over hoe je ze kunt minimaliseren.

Cross-site Scripting

XSS of Cross-site Scripting is een van de beruchtste vormen van aanvallen op applicaties. Het voegt kwaadaardige scripts toe aan applicaties, waardoor het bijvoorbeeld mogelijk is om gebruikersinvoer te onderscheppen en schadelijke functionaliteiten zoals Trojans aan pagina's toe te voegen.

Gelukkig hebben frameworks zoals React en Angular al ingebouwde preventie om XSS-aanvallen te voorkomen. Zo worden bijvoorbeeld alle gebruikersinvoer en waarden die in de DOM worden geplaatst automatisch geëscaped, waardoor <script>-tags worden genegeerd en weergegeven als strings. Als er toch rechtstreeks HTML moet worden geschreven, is het belangrijk dat de HTML wordt gesanitized, bijvoorbeeld met de pakketten sanitize-HTML en DOMPurify.

Cross-site request forgery

CSRF is een beveiligingsaanval op applicaties waarbij een browser wordt misleid om een ongewenste actie uit te voeren in een applicatie waarin een gebruiker al is ingelogd. Als voorbeeld, een gebruiker is ingelogd op een website. De aanvaller gebruikt vervolgens deze sessiegegevens om zich te identificeren op een andere pagina, waardoor ze verzoeken namens de gebruiker kunnen versturen. Dit stelt de aanvaller in staat om bijvoorbeeld wachtwoorden te resetten of accounts te verwijderen.

Een manier om CSRF-aanvallen te voorkomen, is door het gebruik van CSRF-tokens. CSRF-tokens zijn gerelateerde paren van tokens die aan gebruikers worden gegeven om hun verzoeken te valideren en te voorkomen dat aanvallers verzoeken namens een andere gebruiker indienen. Een frontend pakket dat de implementatie vereenvoudigt, is csurf, een middleware die tokens maakt en toevoegt aan alle verzoeken om te valideren dat ze zijn ingediend door een legitieme gebruiker.

Bibliotheken van derden

Bibliotheken van derden worden veel gebruikt bij het bouwen van applicaties. Voorbeelden hiervan zijn hulpmiddelen voor datum en tijd, 3D-graphics en animatiebibliotheken. Deze bibliotheken zijn uiterst handig voor ontwikkelaars, omdat ze niet telkens het wiel opnieuw hoeven uit te vinden.

Echter, dit gemak brengt ook risico's met zich mee. Aangezien de bibliotheken van derden niet zijn geschreven door het interne ontwikkelingsteam, brengen ze 3 primaire risico's met zich mee:

• Gebrek aan controle over wijzigingen in de client-applicatie

• Uitvoering van onvoorspelbare code op clientsystemen

• Lekken van gevoelige gegevens naar derden

Een voorbeeld is de ontwikkelaar "wozheqirsplu" die een npm-bibliotheek had gepubliceerd om ontwikkelaars te helpen hardware-specificaties te bekijken. Ze besloten er geld mee te verdienen door een cryptominer toe te voegen (link). Dit is zeker niet gewenst door gebruikers, omdat ze onbewust hun hardware laten draaien voor iemand anders zijn winst.

Er zijn verschillende manieren waarop ontwikkelaars deze risico's kunnen beperken. Bijvoorbeeld, waar mogelijk, is het verstandig om je eigen hook of hulpmiddel te maken om een probleem op te lossen. Mocht het toch nodig zijn om een bibliotheken van derden te gebruiken, dan kunnen tools zoals Retire.js en de OWASP dependency check helpen bij het detecteren van kwetsbaarheden in pakketversies.

De risico's zitten niet alleen in de code

Veel van de beveiligingsinbreuken (82% volgens Verizon) liggen niet in de tools die werknemers gebruiken of de geschreven code, maar in de invloed van een kwaadwillende persoon die sociale manipulatie gebruikt.

Bij Triple hebben we een beveiligingsbeleid dat Triple-breed wordt ondersteund om beveiligingsinbreuken te voorkomen. De beveiligingsfunctionaris van Triple is verantwoordelijk voor het toezicht op informatie- en cyberbeveiliging en voor het aandachtig houden van werknemers voor het beveiligingsbeleid. Enkele algemene suggesties uit ons beleid om de beveiliging binnen een organisatie te verbeteren zijn:

• Gebruik een wachtwoordmanager voor het registreren van wachtwoorden

• Klik niet op links in e-mails van een valse domein, e-mails met verkorte URL-links of een onderdeel dat u aanspoort om onmiddellijk actie te ondernemen ('Log nu in, anders deactiveren we uw account')

• Verwijder wat u niet gebruikt/nodig heeft

• Download officiële apps van de officiële bron (Bijvoorbeeld: de CitizenM-app van de Google Play Store)

"Onthoud dat het prima is om vragen te stellen. Als iets niet goed voelt, onderzoek het dan. Een minuut besteden aan het bellen van iemand op een nummer dat onafhankelijk is van de e-mail die je zojuist hebt ontvangen, kan het bedrijf duizenden besparen". - Zoë Rose

Het is nu aan jou

Nu je een aantal richtlijnen hebt voor een meer veilige aanpak van frontend ontwikkeling, is het tijd om ze te implementeren. Door bij elke stap in de levenscyclus van de software rekening te houden met beveiliging, blijft het beheersbaar en evolueert het niet tot een probleem dat achteraf moet worden opgelost. Deze praktijk wordt Security by Design genoemd en hier is meer informatie te vinden.

Onthoud, beveiliging is niet iets wat je eenmalig implementeert en dan denkt: 'Oké, het is nu veilig'. Het is een iteratief proces gedurende het ontwerpproces, waarin je voortdurend kunt verfijnen en verbeteren. Het is de enige manier waarop je voor kunt blijven op mensen met kwaadwillende bedoelingen, en de enige manier waarop je je gebruikers een veilige en comfortabele gebruikerservaring kunt bieden.