Hoe gebruik je een veilig frontend-framework voor je website?

Wat is een Frontend Framework?

Een framework is een toolkit—een startpunt voor het ontwikkelen van je website. Het standaardiseert de manier waarop je je software structureert, de code, en regelt veel zaken die elke website nodig heeft, zoals gegevensopslag of het bouwen van pagina's. Dit laatste is een perfect voorbeeld van wat een framework biedt voor de "voorkant" van de website, vandaar de naam frontend framework. Op basis van onze ervaringen met kwetsbaarheden in de praktijk, zijn hier de drie belangrijkste tips voor het veilig gebruiken van frontend frameworks.

1. Vertrouw Niet op je Frontend

De frontend wordt frontend genoemd omdat het het deel van de websitecode is dat draait op de computer, laptop of mobiele apparaat van de bezoeker. Dit betekent dat je de frontend niet moet vertrouwen. Iemand met kwaadwillende bedoelingen kan gemakkelijk de broncode van de frontend bekijken of aanpassen. Daarom is het cruciaal dat de backend, de serverzijde van de website, niet afhankelijk is van de frontend om beveiligingscontroles uit te voeren; deze moet ze onafhankelijk doen. Dit omvat het verifiëren van gebruikersauthenticatie en of een geauthenticeerde gebruiker toegang heeft tot gevoelige gegevens. Bovendien is de broncode van de frontend openbaar, dus het is niet de plek voor gevoelige informatie of geheimen zoals wachtwoorden of API-sleutels.

2. Ken de Beperkingen van je Framework

Een frontend framework is ongelooflijk nuttig, vooral om één specifieke kwetsbaarheid te voorkomen die een derde van de websites treft: cross-site scripting (XSS). Als een website kwetsbaar is voor XSS, kan een kwaadwillende persoon een stuk schadelijke code gebruiken om andere sitebezoekers aan te vallen. Meestal kan de aanvaller niet iedereen op de site tegelijk aanvallen zonder extra stappen, zoals het laten klikken van het slachtoffer op een specifieke kwaadaardige link.
Frontend frameworks zijn effectieve hulpmiddelen om XSS-kwetsbaarheden te voorkomen omdat veel frameworks automatisch de juiste codering toepassen, waardoor invoer als data wordt weergegeven in plaats van als code. Desondanks zijn frontend frameworks geen magische oplossingen, en moet je als ontwikkelaar rekening houden met veel uitzonderingen. We zullen binnenkort op de details ingaan. Als je geen ontwikkelaar bent, kun je doorgaan naar punt 3 over updates.

2.1 Theorie van Frameworks

Cross-site scripting ontstaat wanneer gebruikersinvoer op plekken in de frontend terechtkomt waar het niet als tekst wordt geïnterpreteerd, maar als HTML of JavaScript. Bijvoorbeeld, als we een zoekfunctie bouwen die toont hoeveel resultaten een zoekterm opleverde, kunnen we vergeten de zoekterm HTML te coderen. Deze vergissing maakt het mogelijk om links te creëren met kwaadaardige JavaScript, die bij het klikken die code uitvoert. Met JavaScript krijgen aanvallers toegang tot gevoelige gegevens van het slachtoffer.

Er zijn in wezen drie basisvarianten van XSS, gecategoriseerd op basis van waar de gebruikersinvoer terechtkomt. In het bovenstaande voorbeeld eindigt het tussen elementtags, in 'innerHTML', maar XSS kan ook optreden wanneer invoer in een HTML-attribuut wordt geplaatst.

Ten slotte is er een unieke variant die speciale URL-voorvoegsels zoals 'javascript:' omvat.

2.2 XSS en Frontend Frameworks

Sommige frameworks beschermen rigoureus tegen alle drie de basisvarianten van XSS, terwijl anderen alleen tegen de eerste beschermen. Laten we drie frameworks bekijken.

2.2.1 Angular

• Als je consequent interpolatie in Angular gebruikt ({{ }}), ben je beschermd. Angular is intelligent genoeg om de eerder genoemde contexten te herkennen. Echter:

• Vermijd directe interactie met DOM-elementen buiten Angular. Bijvoorbeeld het manipuleren van de DOM met ElementRef. Dit maakt gebruik van ingebouwde browser-API's waarbij gebruikersinvoer mogelijk niet veilig wordt verwerkt.

• Overschrijf de veiligheidsfuncties van Angular niet. Je kunt bepaalde inhoud als veilig markeren met functies zoals bypassSecurityTrustHTML, maar dit omzeilt de ontsnappingsfunctie van Angular en brengt een risico op XSS-kwetsbaarheden met zich mee.

• Vermijd het dynamisch genereren van templates, zoals het toevoegen van strings aan templates of het gebruik van een andere templatingtaal. Ontsnapping vindt alleen plaats tijdens het renderen van de template, dus de template zelf moet vertrouwd zijn. Elke gebruikersinvoer die in de template wordt opgenomen, brengt XSS-risico's met zich mee.

2.2.2 Vue.js

Vue.js biedt ook sterke ondersteuning. Bij gebruik van tekstinterpolatie ({{ }}) wordt gebruikersinvoer HTML-gecodeerd, waardoor het veilig is om tussen HTML-tags te plaatsen. Toch moet je rekening houden met:

• In de meeste gevallen is gebruikersinvoer in dynamische attribuutbindingen veilig, maar voorzichtigheid is geboden bij attributen zoals 'src' en 'href', omdat Vue.js alleen dubbele aanhalingstekens (") encodeert. Een 'javascript:'-prefix kan dus blijven bestaan.

• Vue.js staat event handlers toe met v-on directives of direct op 'native' event-attributen, maar wees voorzichtig: gebruikersinvoer in zulke attributen wordt behandeld en uitgevoerd als JavaScript. HTML-encoding via tekstinterpolatie helpt weinig omdat de invoer zich niet in een HTML-context bevindt, maar in een JavaScript-context.

• Net als bij Angular interpreteert directe DOM-manipulatie in Vue.js, zoals het gebruik van v-html, renderfuncties of JSX, invoer als HTML, wat risico's met zich meebrengt wanneer dit gecombineerd wordt met (potentiële) gebruikersinvoer.

• Net als Angular is het dynamisch genereren van templates in Vue.js riskant. Ontsnapping gebeurt bij het renderen, dus onbetrouwbare templates door toegevoegde gebruikersinvoer brengen XSS-risico's met zich mee.

2.2.3 React

• React volgt een vergelijkbare aanpak. JSX dient om HTML-elementen te definiëren, waarbij JSX-inhoud wordt geëvalueerd als JavaScript-expressies, die vervolgens HTML-gecodeerd worden, wat veilige opname tussen HTML-tags garandeert. Toch moet je letten op:

• React ontsnapt ook alleen dubbele aanhalingstekens (") in attributen. Wees daarom voorzichtig met 'src' en 'href' attributen waar 'javascript:'-prefixes kunnen blijven bestaan.

• In React leidt directe DOM-manipulatie via dangerouslySetInnerHTML of DOM-interactie met findDOMNode/createRef tot het omzeilen van React's standaard ontsnapping, wat XSS-kwetsbaarheden veroorzaakt.

• Het is gebruikelijk in React om componenten te instantieren met de spread-operator (bijv. <div { ...properties }>). Echter, als een gebruiker het properties-object aanpast, kan hij via 'dangerouslySetInnerHTML' scripts injecteren, wat leidt tot XSS-risico.

3. Houd Software Up-to-date

Software-updates en afhankelijkheidsbeheer zijn altijd een beveiligingsuitdaging, zeker voor frontend frameworks. Het is cruciaal om periodiek te controleren op nieuwe kwetsbaarheden, omdat deze vaak opduiken en relevant kunnen zijn voor jouw situatie. Hulpmiddelen kunnen helpen; veel package managers kunnen automatisch controleren op bekende kwetsbaarheden (zoals npm audit), terwijl dependency scanners automatisch update pull requests kunnen aanmaken (zoals Dependabot).

Tot slot, wees kritisch op de software waarop je vertrouwt. Elke extra bibliotheek vergroot je aanvalsoppervlak, kan onbekende kwetsbaarheden bevatten, vereist tijdige updates en kan zelf gecompromitteerd raken. Beperk daarom software-afhankelijkheden en gebruik alleen vertrouwde bronnen.

Conclusie

Wil je een frontend framework veilig gebruiken? Zo doe je dat:

1. Vertrouw je frontend niet. Gebruik de backend voor geheimen en essentiële beveiligingscontroles.
2. Wees je bewust van de beperkingen van je framework. Een framework is alleen veiliger als het correct wordt gebruikt.
3. Houd software-updates in de gaten en zorg voor tijdige beveiligingspatches.

Benieuwd of jouw frontend veilig is? Laat ons je broncode beoordelen. We doen diepgaand onderzoek om kwetsbaarheden te identificeren en geven feedback op architectuur- en ontwerpkeuzes, zodat je zwakke plekken kunt aanpakken.
Neem contact met ons op via: [email protected].